Hello, we just released 0.17.73, with 0.17.74 coming very soon. This is just some bug fixes and further pathfinding improvements, and we hope to be able to mark the release as Stable next week.

It's the last Friday of 2018, and as such the last Friday Facts before the New year of 2019. We all hope everyone has had a great 2018, and looking forward to a lot more automation fun to come in 2019. Albert has produced a postcard for you all to share to give the year a good send-off.

Factorio Nomenclature Abregado Today I want to discuss some common problems that we see in video games. Inconsistent Terminology When I asked out loud "So what is an Intermediate Product anyway?", I got a similar reaction as when someone mentions The Berlin Interpretation at a rougelike convention. So what is an Intermediate Product? Well it is a product that is used only as an ingredient for something else. No, that's not right because Science Packs are not used in any recipe. So what then, Intermediate products are just things that you can use Productivity Modules on? Perhaps they are simply items that can be found in the Intermediate Crafting menu. Then are they not Intermediate Recipes? To give another example, answer these questions: Name the action a player performs when they add an entity to the world? Name the action a player performs when they remove an entity from the world? Name the action a player performs when they add a ghost entity to the world? Name the action a robot performs when they add an entity to the world? Name the action a robot performs when they remove an entity from the world? Here are a few situations where the game displays your possible answers: A player builds. A player mines entities. Robots repair and build entities, but wait… the player places buildings and builds ghosts? But here Robots are constructing machines. Here the robots are deconstructing items! This leads into a discussion about what is an item and what are entities, and that discussion leads us into the next point... Internal nomenclature leaking out During game development it is very common to use internal names to refer to mechanics, items, or characters. It does not feel like such a big deal, and many early access games simply ignore the problem completely. I'm not going to point any fingers, but if you look you will find some examples. Oh wait, here is some from your favourite early access game! Internally, things that exist on a surface in the game are called entities. All these items are capsules internally, but only 5 of them are actually labelled as capsules. Really, these should be categorised by how players use them, and indeed there is an attempt to do so. Remotes are items used to trigger an effect, Grenades are things you throw... but why is the Poison Capsule not called a gas grenade? There are more inconsistencies but to keep this article reasonably not-short, I will let you find the others yourself (and to save something for a future FFF about Tooltips). Why change? You might be thinking that this is not a big problem. Some others might be thinking that the problem is too pervasive to bother changing. There are a few reasons why it is important, the first, and most important of which is our quality mindset; everyone on the team here wants the game to be as great as possible. Next we should see this increase the quality of the translations. A translation is only as good as its source, and having a consistent usage of words can go a long way to helping the translators do better work. The effect of this can be increased by providing a dictionary of important words to the translators so they can be sure to always use the same term in all places. Since we are also working on a guided experience (Campaign), this would also help us give much clearer instructions to the player. An example of confusion here would be if one quest said "Place a chest" and another said "Place the item in the chest". The player needs to read the entire quest caption (probably twice), and can never build up a mental map of our language. This leads to the player spending more mental energy (cognitive load) while playing the game. Changing this to "Build a chest" and being consistent, allows the player to create mental shortcuts, meaning the quest tasks require less effort to understand. Finally, consistency in terminology will help new players, and I don't just mean sub-1 hour playtime players. Factorio is a 'Big Game' and players are encountering new items, entities, concepts, and text for a long time. How many hours did you play before you discovered this helpful trick, or this one? How to change? We could make the vocabulary consistent with what the current player base uses. This option sounds pretty good until I started asking people questions similar to those I asked you at the beginning of the article. Here are another two as a refresher: Where do biters come from? I come in 7 colors, what am I? The only wrong answer is if you said there was only a single right answer. Prepare your rotten tomatoes, Ben is about to say something unpopular. The influx of players that are to be expected from 1.0 give us an interesting option. We could theoretically change the vocabulary of the game to be more consistent, reasonable, and generally more helpful to players. Then, as new players join the community, this new language will slowly replace the old. This would help ease communication between all players; veterans and new addicts alike. Consistency will also help polish the experience to the level that players expect from the game. Who should change it? Before Rseding jumps in with some awesome news, I would ask you to have your say in this Google form. It will be fun to see what you come up with, and I will publish the results in a few weeks.

Hello, the regular dose of news from the developement of Factorio is here, I (Kovarex) wrote it today, and you can clearly see, that I like structured form of information :) Factorio is a continuous jam session. Albert had this observation yesterday and it is very precise description of our development. In the start I had no idea what will the game be like, I had no plans about the visual styles and proportions of the project that was just a hobby, an experiment. The rails were the first graphical assignment for Albert. I told him to just "do the rails" like it was some obvious one way street task. I didn't give him any clues about the style. Should it be cartoonish? Should it be realistic? Should it look modern, cyberpunk or 19th century like? We didn't know, we were searching for the direction on the fly. Any manager would probably say this is a bad thing, that we need a roadmap for the whole process from the start to the final release with all the contents, features and graphics planned ahead including cost estimates. I personally think, that the freedom of the jam (agile) way of development that allows us to react is the best for Factorio. We are inventing and extending the best ideas on the run, ideas that would never be visible in the start. The 0.8 We have less than a week for the preparation of the 0.8, we integrated all the new terrain tilesets to the game, Tomas is now working on the roboports, and construction robots can reconstruct destroyed buildings. We have few days to add some smaller features before we start bugfixing and preparing for the release. The new terrain The main graphical task of the 0.8 is almost finished. You can judge for yourself: The roboport The roboport is the control building for the logistic/construction robots, it will provide the radio signal with limited range for these to operate. This will limit the robots from following the player out of the factory and allow the player to have more distinct logistic systems. Apart from that, the robots will recharge there and stock inside if they have nothing to do. Reconstruction of destroyed buildings When any building owned by player is destroyed while he has the construction robots researched, the half transparent "ghost" building appear on top of the remnants. This ghost building has limited lifetime (5 minutes) and if the needed component is available in the local logistic system, the construction robots take it and automatically reconstruct the building. Nothing new, but still: the thread for comments is available on our forum.

Hello, We are down to 28 bugs on the forum. The last bugs are often the ones we have been putting off for a reason, they generally require some more meaningful changes and decisions. That is why this week we have a lot to discuss.

Lua Mod GUI additions Rseding Mod GUIs have been an interesting part of Factorio modding since I started working at Wube. They allow scenarios and mods to add GUIs that look and feel like the base game. When someone new to Factorio modding is introduced to how they function, they almost always have the same questions: Why is mod GUI part of the game state? Why do mod GUIs need to be deterministic? How can I edit the base game GUIs? And then comes the explanation: The actual widgets are not part of the game state and are not deterministic. The part that mods have access to however is. In an environment where mods have to operate deterministically, if a mod is allowed to read some data that data must be deterministic. In that simple bit of logic; if a mod can read the checked state of a checkbox then that checked state needs to be deterministic. If the mod didn't have access to read that state it would need to store the last-known state and update it every time it got the changed event. Try to imagine that: every single mod implementing their own system for remembering last-known-state about GUIs they're using. Instead of leaving that entire mess to mod developers we decided long ago that we would manage that "last-known-state" for them. The basic data about what a given mod wanted to show on screen is recorded so mods can read and change it as they want and not need to be concerned with constantly updating it every time some changed event happens. Additionally it means that the game can use that "last known state" to restore what the player sees if they save, quit, and load the game. That still leaves the last question: "How can I edit the base game GUIs?". Using the above example it's much easier to explain that: as a mod - you can't. The base game GUIs are not implemented using this same system - they're just pure collections of widgets. None of the "last known state" is saved anywhere and it's all lost when saving, quitting, and loading. However, that leaves a divide: we need to implement each widget type through the "CustomGui" system in order for mods to be able to use them. With this latest release I finally figured out a way to do tabbed panes since they're special in how they work compared to everything else. Additionally I figured out a semi-friendly way for mods to put things directly on the screen in a way that the player can drag them around - instead of being limited to some fixed area (left, top, center, etc). Another system which I've been thinking about for quite some time is some way for mods to position GUI elements relative to base game GUIs. For example: a mod wants to add a pane which shows on the left of the character inventory GUI. Currently it's not possible - the base game GUI isn't readable by mods so they can't do anything with it. My idea is some system where a mod can say "I want to add this GUI, and I want it to be shown relative to the character GUI on the left side" and then any time the character GUI is shown it would also show the mod GUI. There are some critical parts to this new system. It needs to: Be easy to expand (either automatically works with all new base game GUIs or works with minimal effort). Not break with simple refactoring. Not cause other programmers trouble by existing. Not prevent base game GUIs from working how they need to work. So far none of it seems impossible. I don't know when I'll have it working, but I'm looking forward to what mods will do with it.

Further optimisations I finished the item stack optimisations mentioned in FFF-198, and was able to do some performance tests. First I tested how many stacks on a big map actually need to use an externally allocated object (Item), and how many of them are plain. On the huge map I tested, it turned out that only 36K out of 1M stacks need the Item object. These were mainly science packs, as they need it for the progress of how used-up they are (and now when I think about it, it could also be omitted by only using the objects for science packs that are partially used up already). Overall factory performance was increased approximately 2% by this. It is nothing huge, but every bit matters. One of the programmer that has read access to the code (Zulan), came up with a pull request that improves performance in Factorio by prefetching memory in the update loops ahead. The problem when normally updating objects is, that CPU asks for memory representing the object. The memory is slow, at least compared to the CPU cache or the CPU speed. The memory transfer speed itself is not that slow, but the waiting (latency) time between ordering and receiving it is. This means, that what very often happens is, that CPU orders data of next entity from the memory, then it waits for quite a long time to get it, and then it does its logic. The memory prefetching partially solves it by doing this: Order data of the next entity from memory (prefetch) Do the logic of the current entity in the meantime Go back to start The overall measured performance improvements vary between 9-12%, which is certainly a nice addition.

The Character GUI Twinsen It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots. ​ The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type. Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request. With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science. Searching now not only searches the recipe GUI, but also the inventory and logistic requests. By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots. Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released. Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be focusing obsessing that much on the GUI in the future. We will finalize the transition of styles, fix obvious issues and low hanging fruits, and try to get everything at a consistent level of quality for 1.0. This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.

Hello, we would like to talk about the remote view changes coming in the 2.0 base game update. This is one of the foundations to be able to talk about the space platform and planets later, so lets get into it!

Hello, we have shown some bigger things recently, so it is time to also show some smaller things, because the bigger things wouldn't shine that good without the smaller things working properly!